In conventional computing systems, the need to access large amounts of complex data is growing at a rapid pace. Accordingly, databases are capable of storing increasing volumes of data with increasingly complex structures. Databases are constantly updated with new versions that enable the storage of additional content and the creation of additional data types. To enable these databases to be efficiently accessed and manipulated, it is necessary to expose database schema information, which is metadata that describes the structure and/or content of the database.
This database schema information is exposed by a database driver. The term “driver,” as used herein, refers to a database driver, database provider, or any middle layer mechanism that provides an application with access to a database. Conventional database drivers may expose database schema information to an application in a number of ways, namely, through query mechanisms, through hard-coded data, or through application program interface (API) calls directly to the database server.
A disadvantage of these conventional exposure mechanism is that they are limited with respect to updating of database schema information. For example, when a database is updated with new content, new data types, or generally any new information, the driver binaries that expose this information must also be updated along with the database binaries. This causes a very tight coupling of the drivers to the database. This tight coupling is particularly problematic when a driver is not ready to ship at the same time as the database itself. For example, a first version of a database (DB.1) may support a data type that is called ServerA_Float_V1. If the corresponding first version driver (d.1) ships at the same time as DB.1, then d.1 will likely be able to provide metadata that describes the ServerA_Float_V1 data type. Later, a second version of the database (DB.2) may support a new data type that is called ServerA_Float_V2. If the corresponding second version driver (d.2) is not ready to ship at the same time as DB.2, then the driver will have no way to provide metadata about the ServerA_Float_V2 data type until d.2 is ready to ship.
Another disadvantage of conventional database systems is that they are limited with respect to the flexibility of database schema information. Specifically, conventional databases define a pre-determined list of collections through which database schema information may be exposed. Additionally, an exact pre-determined format is also required for each of the pre-determined collections. These pre-determined collections and formats are problematic because the structure and content of conventional databases is highly variable and greatly dependent on the particular applications for which the data is used. Furthermore, conventional databases require both content and structure to be described in a single collection. This combination of content and structure forces collections to be unduly large and complex, thereby increasing the time required to read and search the collections to generate results. Accordingly, there is a need to improve upon the conventional systems and methods for the exposure of database schema information.